Dynamic systems, which are human-devised systems that respond in some beneficial way to changing conditions within their environment, represent a significant challenge to the designers of such systems due to the myriad and diverse conditions such systems must be capable of handling effectively. For example, electrical and electronic circuits, which represent but one type of dynamic system, often must react to ever-changing input signals by providing output signals based on the input signals, thereby causing some favorable action in the environment in which the system operates. Electrical and electronic circuits are utilized to great advantage in a plethora of applications, from everyday consumer appliances, such as microwave ovens and personal computers, to high-tech military weaponry. Additionally, dynamic systems also include any type of software written to perform a specific, useful function. Furthermore, dynamic systems may include, but are not limited to, those based on electrical, software, mechanical, pneumatic, or chemical principles, or some combination thereof.
The task of designing dynamic systems has been greatly enhanced by continual improvements in the technology of system simulation. Such simulation allows models of dynamic system designs to be tested initially without the need of expensive prototypes that are difficult to both build and maintain. Through simulation, any imaginable set of test conditions may be employed to thoroughly exercise a preliminary system design. The results of those tests may then be used by the system designer to analyze the performance of the system. Typically, changes are then made based on the results of the tests, the tests are rerun, and the results are analyzed once again to determine the positive or negative effect of the changes. Thus, simulation allows the design of the dynamic system to be improved by way of an iterative process prior to the actual construction of the system under test, resulting in faster and more productive system development.
A specific example of such a modeling environment is the Simulink® system definition and simulation tool by The Mathworks, Inc. As shown in FIG. 2, a modeling environment 210 allows a system designer to specify a dynamic system, whether it is electrical, mechanical or otherwise, by way of a system model 1 possessing characteristics as determined by the designer. An example of the system model 1 is shown in FIG. 1. The system model 1 consists of several functional blocks 2, each of which performs some identifiable task within the system model 1. Ordinarily, one or more input signals 3 and output signals 4 (or, collectively, external variables) are utilized by the dynamic system represented by the model 1 to communicate with and influence the surrounding environment. Internal signals 5 of the system model 1 allow the functional blocks 2 to communicate, thereby allowing cooperation among the functional blocks 2 to perform the overall function of the dynamic system. Most modeling environments 210, such as Simulink, also allow hierarchical design, as each block 2 of the system model 1 may further consist of sub-blocks (not shown) representing various functions within the associated higher-level block 2.
Additionally, the functional blocks 2 within the system model 1 may be predefined functional blocks (e.g., differentiation or integration functional blocks) that are normally made available within the modeling environment 210, while others are later-defined functional blocks whose behavior may be specified by the system designer. Such later-defined blocks may be specified within the Simulink environment by way of “S-functions,” which allow the behavior of the block to be specified by way of user-supplied or third-party-supplied software, which may be written in any of several different languages, including C, Ada, and Fortran.
As seen in FIG. 2, the system model 1 specified in the Simulink environment may then be simulated within that same environment using input signals 3 devised by the system designer. The analysis, subsequent design changes, and further simulation of the model normally all occur within the purview of the Simulink tool. To enhance this process, Simulink allows access to the internal signals 5 of the system model 1 that help define the behavior of the proposed system. Specifically, the internal signals allow the designer more insight into the operations of the system model 1. Thus, access to these internal signals 5 makes the entire simulation and analysis process more efficient.
A related code-generation tool 220, such as that provided by The Mathworks, called the Real-Time Workshop® (RTW), takes system models originally developed within the modeling environment 210 as input, and generates code that is a software model 230 representing the system model. The software model 230 can be generated in one of several different programming languages, including C, Ada, and others. The software model 230 may then be transferred to and executed on another platform, with the execution of the software model 230 possibly progressing in real-time, depending on the nature of the platform. In the case of software systems, the platform may be the target platform ultimately used to implement the system, thus providing a nearly seamless progression from system model generation to production-level code.
Unfortunately, the system internal signals 5 of FIG. 1 that are initially accessible in the simulation environment 210 are often no longer accessible on the platform executing the software model 230 without additional model-specific software that has been specially created by the designer. In an effort to remedy this situation within the Mathworks environment, the RTW tool provides an “external mode” option, which allows the designer access to the internal signals of the software model 230 when accessed via the Simulink environment. In external mode, such internal signal access via Simulink is possible whether the software model is executed on the same platform which is executing Simulink, or on another platform which is connected to the Simulink platform by way of a communications link, such as Transmission Control Protocol/Internet Protocol (TCP/IP). However, the form and quality of access to the internal signals of that code running on a separate platform is dependent upon the capabilities of Simulink, as well as the availability of a communications connection between the Simulink platform and the platform hosting the RTW-generated code. The ability to access the internal variables of an executing software model by way of a client application residing outside the original modeling environment is currently not available.
Therefore, from the foregoing, methods that automatically allow access to the internal signals of a system model by way of that system model, or by way of a software model generated from the system model, from outside of the original modeling environment would be advantageous. Such methods would allow the system designer greater flexibility in the platforms upon which to simulate the system model, as well as possibly allow the designer more flexible and effective access to the internal signals of either of the two models.